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selecting a subset of the plurality of data streams, wherein the selected subset of audio 
data streams includes streams of different audio/video protocol types; 

routing the selected subset of the plurality of audio data streams to decoder modules 
based on their audio/video protocol types; 

rendering the selected subset of data streams; 

determining whether one or more of the first and second data streams is associated with 
an inactive conference participant; and 

substituting a third data stream from a third conference participant, for at least the one of 
the first and second data streams determined to be associated with the inactive conference 
participant. 

35. (Amended) The system of claim 1 , wherein the data streams in the selected 
subset are most recently activated data steams. 

REMARKS 

Claims 1-8, 18-26, 28, 29 and 31-36 are pending in this application, stand rejected, and are 
at issue herein. Reconsideration and an indication of the allowance thereof are respectfully 
solicited. Claim 22 has been amended to correct the Claim number from which it depends for 
purposes of clarity only, and no new matter has been added thereby. Claims 3 and 35 have been 
amended to correct typographical errors for purposes of clarity only, and no new matter has been 
added thereby. Claims 3, 4, 18, 21, 24, 25, 26, 29 and 32 have been amended to improve clarity as 
discussed below, and no new matter is added thereby. 

Rejection of Claims 1 and 21 - Smith in view of Clapp 

Claims 1 and 21 stand rejected under 35 USC § 103(a) as being unpatentable over Smith, 
U.S. Patent No. 6,128,649 (hereinafter "Smith") in view of Clapp et al., U.S. Patent No. 4,802,281 
(hereinafter "Clapp"). The Applicant respectfully traverses the rejection and requests withdrawal 
of the rejection based on the arguments and remarks presented below. 
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To establish a prima facie case of obviousness, 35 USC § 103(a) requires that three criteria 
be met. There must be some suggestion or motivation to modify a reference or to combine 
reference teachings; a reasonable expectation of success; and the prior art reference or references 
must teach or suggest all the claim limitations. See MPEP 2142. 

The last element of Claim 1 requires "the receiver including a demultiplexer for 
dynamically selecting a subset of the set of data streams and two or more receiver payload 
handler modules and two or more corresponding decoder modules for handling and decoding 
two or more types of the data streams." Neither Smith nor Clapp, taken alone or in combination, 
teach or suggest the last element of Claim 1 . 

First, Smith fails to teach "the receiver including a demultiplexer for dynamically 
selecting a subset of the set of data streams." Smith, Col. 1, lines 53 -62 refers to a prior art 
multiplexer used in known video conferencing arrangements via a multicast control unit (MCU) 
that multiplexes and uses the MCU for " all video streams transmitted by the network 2 to and 
from users 3 gives a centralized topology ." A centralized topology for multiplexing all video 
streams is different from Claim 1, which requires a "demultiplexer for dynamically selecting a 
subset ". A "subset" is not the same as "all". See Smith, Col. 1 , lines 54 - 57. Further, Smith, 
Fig. 21, element 13 refers to a dynamic selection controller. The function of the dynamic 
selection controller is to determine the "actual selection requests on the basis of the policy and 
the conditions. The network 12 then passes the selected media streams to the user on the basis of 
the request made by the dynamic selection controller 13.... The dynamic selection controller ' 
may issue selection requests...." Col 6, lines 53 - 60. Thus, the dynamic selection controller is 
not a "demultiplexer for dynamically selecting a subset," since the dynamic selection controller 
13 only makes requests. Rather, the "heart of the dynamic selection control function" is the 
membership decision module (MDM). Smith Col. 8, lines 25 - 27. However, the MDM, as 
shown in Fig. 6 is not a demultiplexer . The MDM provides requests as shown in Fig. 6 as the 
"Connection Membership Signaling" fed to network 24. Rather than "dynamically selecting a 
subset" MDM 38 may "request fewer media streams to be transmitted." Col 8, line 60. As one 
of ordinary skill in the art appreciates, the function of a demultiplexer is different from a module 
that requests media streams prior to transmitting as taught by Smith. 
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The data multiplexer taught by Smith teaches away from a demultiplexer as described in 
Claim 1 . More specifically, Col. 27, lines 31 through 55 refers to a data multiplexer at a "local 
cable hub or distribution control point" which teaches away from "the receiver including a 
demultiplexer" as required by Claim 1. The embodiment referred to in Col. 27 discloses using 
two separate networks, a higher bandwidth network and a lower bandwidth network with the 
lower bandwidth network for transmitting a single stream. See Col. 27, line 40 - 44. Rather than 
the "receiver including a demultiplexer," Smith refers to a hub for multiplexing telephone lines 
to connect each user to the lower bandwidth network, which would necessarily occur prior to 
"receiving" as required by Claim 1. Col 27, lines 45 - 55. Thus, the data demultiplexer required 
in Claim 1 is so substantially different from the items cited as equivalents in the Office Action 
dated July 8, 2002 that to apply the data multiplexer of Smith to Claim 1 would change the 
principle of operation of Smith contrary to the requirements of MPEP 2143.01. Accordingly, 
combining Smith with Clapp for the purpose of teaching a demultiplexer of Claim 1 would be * 
improper. 

Second, neither Smith nor Clapp, either alone or in combination teach "two or more 
corresponding decoder modules for handling and decoding two or more types of the data ; 
streams" as required by Claim 1 . Rather, Smith, Col. 20, lines 11-18 provides for processing 
modules 28 and 34, which as shown in Fig. 5b refer to video and audio streams respectively. 
The modules 28 and 34 "have the generic function of receiving a stream from a network 
connection, and performing all the necessary steps required for the proper presentation of the 
stream to the user. These will be specific to the type of media that constitutes the stream . . .." 
Smith, Col. 20, lines 12-17. Thus, Smith teaches two modules (D or T) both of which together 
will receive a single data stream which teaches away from "two or more corresponding decoder 
modules . . . decoding two or more types of data streams." Moreover, because Smith teaches 
decoders that are "specific to the type of media" that constitutes one data stream, Smith teaches 
away from the invention making Claim 1 not obvious under MPEP 2141 .02, which provides that 
prior art must be considered in its entirety, including disclosures that teach away from the claims. 
Therefore, it is improper to combine Smith with Clapp because the references teach away from 
their combination. In re Grasselli, 713 F.2d 731, 743 (Fed. Cir. 1983). 
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Clapp teaches a peripheral video conferencing system adapted for communication with 
an analog or digital communication channel and a separate host computer system. The cited 
portions of Clapp from the Final Office Action dated July 8, 2002 do not relate to decoding audio 
or video data. Col. 5, lines 1-5 and 20 - 22 relate to uncoupling/separating audio and video 
processing assemblies and the peripheral housings used by the communication system 70. 
However, Col. 8, lines 41-58 describes producing a combined audio/video signal, with central 
controller 200 operating to transmit an audio signal to an audio processor 1 84 and video signals 
to a video processor 1 88. The video and audio processors are CODEC chips for encoding and 
decoding the audio and video signals. Col. 9, lines 47-60. 

Importantly, Clapp fails to discuss, teach or suggest "two or more corresponding decoder 
modules for handling and decoding two or more types of the data streams" as required by Claim 
1 because the "type of data stream" is not discussed. Referring to the specification, page 8, line 
22, examples of data types are provided including "audio G.71 1, audio G.723.1, video H.261, 
and video H.263." Thus, the term "type" referred to in the Applicant's Claims refers to an 
audio/video protocol type. See also, Specification Page 2, lines 14-18. As is known, an 
Applicant can be his own lexicographer. Where an Applicant provides an explicit definition for 
a term that definition for the term will control the interpretation of the term as it is used in the 
claims. Toro Co. v. White Consolidated Industries Inc., 199 F.3d 1295, 1301 (Fed. Cir. 1999). 
In re Hill, 161 F.2d 367 (CCPA 1947). Therefore, to characterize "types of data streams" to 
broadly refer to video and audio and not, as defined in the Specification as audio/video protocol 
types would mischaracterize the Claims in violation of Toro. Although, as pointed out in the 
Final Office Action dated July 8, 2002, Page 1 1, claims are interpreted in light of the 
specification and limitations from the specification are not read into the claims, the term "type" 
is clearly defined in the Applicant's Specification to mean audio/video protocol type and that 
definition controls the interpretation of the Applicant's Claims. Because the definition of type is 
controlled by the Specification, for purposes of clarity only, the Applicant has amended Claims 
3, 4, 18, 21, 24, 25, 26, 29 and 32 to conform to the Specification definition of "type." 
Therefore, no new matter has been added. Further, because the term "type" is merely being 
conformed to the appropriate definition of type as required by the Specification, no new search is 
believed required due to the amendment. For the reasons provided above, neither Smith nor 
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Clapp, alone or in combination, teach or suggest "two or more corresponding decoder modules 
for handling and decoding two or more types of the data streams" as required by Claim 1 . 
Claims 2-8 and 35 depend from Claim 1 and are believed allowable with Claim 1 for at least 
this reason. 

Regarding Claim 21, neither Smith nor Clapp, either alone or in combination, teach the 
second and third elements, "dynamically selecting a portion of the RTP data streams; and routing 
one or more RTP data streams of the portion based on data type." As discussed above, "based on 
data type" refers to an audio/video protocol type. Smith, Col. 1, line 53 through Col. 2, line 6 
discusses a prior art video conferencing technique for multiplexing all video streams. In Smith, a 
chairman controls a centralized multicast control unit to select one of the incoming video streams 
or add video streams, however, the data stream chosen by a chairman is not based on type as 
defined in the Specification and discussed above with reference to Claim 1 . Therefore, Smith 
fails to teach "routing one or more RTP data streams of the portion based on a data type" as 
required by Claim 21. In light of the foregoing, Applicant respectfully believes Claim 21 is 
allowable. Claims 22 and 23 depend from Claim 21 and are believed allowable with Claim 21 for 
at least this reason. 

Rejection of Claims 2-8, 18-20, 22-26, 28, 29 and 31-36 - Smith in view of Clapp and Bar * 
Claims 2-8, 18-20, 22-26, 28, 29 and 31-36 stand rejected as being unpatentable over Smith, 
in view of Clapp and in further view of Bar et al. (Bar), U.S. Pat. No. 6,122,665. Applicant 
respectfully traverses the rejection. 

Bar teaches a system and method for monitoring a computer network to detect data packets, 
such as audio and video data, and recording and storing the data for later reconstruction upon 
request. Col. 1, line 6 through Col. 2, line 11. Further, Bar operates without regard to initiating 
communication sessions: "However, the system of the present invention only monitors, rather 
than initiating, such communication sessions . Thus the system of the present invention uses the 
H.245 signaling to determine when the communication session has started in order to effectively 
record the necessary data packets for the storage and later reconstruction of the session . " Col. 
1 1 , lines 44 - 50. Therefore, Bar is not related to "a system in a network conferencing 
environment" (Claims 2-8); Bar is not related to a "method of conducting a network conference" 
(Claims 18-20); Bar is not a "network conferencing system" or a "conference system" (Claims 
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22-26, 28, 29 and 31-36): Rather, Bar relates to a storage and retrieval system. A conference 
system necessarily includes "participants" that participate in receiving and transmitting. A 
storage and retrieval system does not require participants. As such, the Bar reference does not 
provide a reasonable basis for success, either alone or in combination with any other reference, 
of teaching the claims at issue. A reasonable basis for success is required for a U.S.C. § 103(a) 
obviousness rejection. Bar, taken as a whole as required by MPEP § 2142.02, does not suggest 
the claims because a reasonable person of ordinary skill would not have viewed a storage and 
retrieval system as being relevant to a system with the payload handler modules of, for example, 
Claim 2 thereby obviating a reasonable basis for success. 

Completely different considerations are at issue in Bar. For example, the system for 
storage and later retrieval in Bar operates differently with regard to the existence of a "data 
stream" or "means for data streaming" as required in Claim 8. Bar provides for streaming data 
thaf is "restored by data restore unit 32" and must synchronize audio and video data when 
restoring previously saved communications. Col. 13, lines 3 - 30. Further, Bar operates without 
regard to "monitoring incoming audio or video data for each of a plurality of conference parties 
for active or inactive status" as required by Claim 1 8 or "means, responsive to determination of 
the inactive conference participant" as required by Claim 24. Rather, active or inactive status is 
irrelevant because Bar provides for "monitoring, logging and retrieval of all audio and/or visual 
calls . . .." Col. 14, lines 49-51. Accordingly, combining Bar with Smith and Clapp is * 
improper. 

Moreover, the cited portions of Bar fail, when combined with Smith and Clapp to teach 
or suggest the elements of Claims 2-8, 18-20, 22-26, 28, 29 and 31-36. Specifically, Bar fails to 
teach "a demultiplexer. . . for routing data to one of the receiver payload handler modules based 
on data type" as required by Claim 3; or "routing the audio or video data from the second 
computer system to a second decoder based on the determination of the type of audio or video 
data" as required by Claim 1 8; or "means for routing data received by receiving means to the 
first or the second decoder module based on data type" as required by Claim 24; or "means for 
routing the selected subset of the plurality of audio data streams to the modules based on the data 
types of the streams" as required by Claim 26; or "routing the selected subset of the plurality of 
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32. 

Bar, Col. 6, lines 5-40 teaches away from routing based on data type as defined in the 
Specification. "Support for voice data is required, while support for general data and video data 
are optional, but if supported, the ability to use a specified common mode of operation is 
required, so that all terminals supporting that particular media type can communicate." Col. 6, 
lines 10-13. Bar further discusses the logical channel signaling procedures of H.245 as 
requiring "that transmissions are limited to information which can be decoded by the receivers, 
and so that receivers may request a particular desired mode from transmitters" thus teaching that, 
rather than demultiplexing, H.245 requires apriori decision making. 

Bar, Col. 8 and 9 teach reconstruction of a prior communication session and is not 
analogous to the Claims. Nonetheless, Bar does not address the "routing . . . based on data type" 
as defined in the Specification. The routing described with reference to Fig. 2 of Bar relates to 
routing based on packet headers (Col. 10) and the type of data discussed relates to the type of 
routing required by a datagram: "A "SERVICE TYPE" portion 48 indicates whether the sender 
prefers the datagram to travel over a route with minimal delay" Col. 9, lines 55 - 57. The "type" 
referred to in Bar is a "packet type" and not an audio/video protocol type. More particularly; 
step 3 A of Fig. 3 A refers to "In step 3 A, second filtering component 40 examines the IP packets 
to determine their type from the data portion of the packet" Col. 10, lines 23 - 28. The "type" 
referred to is shown as H.225, H.245, RTP and RTCP. This "type" is not an audio/video 
protocol type as defined in the Specification. Rather, the types referred to in Bar relate to 
communication protocols for which the data packets contain data for purposes of routing . See, 
e.g., Col 10, line 40. Thus, it would not be obvious to one of ordinary skill in the art at the time 
of the invention to modify an existing system such as that of Bar to route based on audio/video 
protocol type. Rather, the discussion in Col. 13 of Bar, which describes different audio/video 
protocols appropriate for CODECs in Fig. 2 does not relate to "routing" or "demultiplexing" 
based on those protocols . In Bar, the routing is predetermined and demultiplexing unnecessary 
because the data was already analyzed and stored in storage 30 . The packets later retrieved 
"fulfill the rules of database 26" prior to storage. Bar Col. 8, lines 5 - 39. Therefore, it would 
not be obvious to demultiplex or route based on audio/video protocol type. 
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Prior to storage of data packets, a filtering module 24 "screens the data packets in order 
to determine which data packets fulfill the following criteria. Briefly, the data packets should be 
IP packets with headers according to the H.225 and H.245 standards, indicating voice and/or 
video traffic. As noted previously, these standards define media stream packet construction and 
synchronization for visual telephone systems and the control protocol for multimedia 
communications." Bar, Col 7, lines 56 - 65. The filter does not, therefore, route or demultiplex 
based on the audio/video protocol type. The filter passes any audio or video packets. Thus, Bar 
teaches a binary decision making process asking whether or not a packet is for voice and/or 
video traffic, making no distinction based on the type of audio or video protocol. Therefore, Bar 
combined with Smith and Clapp fails to teach "means for routing the selected subset of the 
plurality of audio data streams to the decoder modules based on the data types of the streams" as 
required by Claim 26 and substantially by Claims 29 and 32, or "means for routing data received 
by receiving means to the first or the second decoder module based on data type" as required by 
Claim 24. Claim 36 depends from Claim 24 and is believed allowable for at least this reason. 
Claim 28 depends from Claim 26 and is believed allowable for at least this reason. Claim 31 
depends from Claim 29 and is believed allowable for at least this reason. Claims 33 and 34 * 
depend from Claim 32 and are believed allowable for at least this reason. 

Claim 25 provides "receiving . . .first and second types of audio data from first and second 
conference participants" and "decoding at least a portion of the first audio data stream in a first 
decoder." As described above, Bar relates to a storage and retrieval system. Thus, Bar does not 
decode audio data received from conference participants. Rather, Bar decodes previously stored 
audio data. The CODEC described in Col. 8, line 64 through Col. 9 line 7 is used for restoring 
communication sessions from reconstructed streams of data, not from participants. Further, the 
converting analog and digital data of Bar is known in the art and does not relate to conversion 
based on "audio type" as defined in the Specification. According to Bar, "an audio CODEC 
enables the digitized audio data. . . to be converted." The type of audio data is not discussed with 
regard to decoding. 

As discussed above, Clapp does not address data "types" as defined in the Specification. 
For this reason and the reasons discussed above, neither Bar, Smith nor Clapp, either alone or in 
combination teach the elements of Claim 25. 
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Therefore, the combination of Smith, Clapp and Bar fails to teach or suggest the elements 
of Claims 2-4, 8, 18-20, 22-26, 28-29 and 31-36 and Applicant respectfully requests withdrawal 
of the rejection. 



Conclusion 



The rejection of Claims 1-8, 18-26, 28, 29 and 31-36 under 35 U.S.C. § 103(a) has been 
traversed. Claims 3, 18, 21, 22, 24, 25, 26, 29, 32 and 35 have been amended for clarity. In view of 
the above, the applicants respectfully submit that Claims 1-8,1 8-26, 28,29 and 3 1 -36 are in 
condition for allowance. Reconsideration of Claims 1-8, 18-26, 28, 29 and 31-36 and an indication 
of the allowance thereof are respectfully solicited. If the Examiner believes that a telephonic 
conversation will aid in the resolution of any issues not resolved herein, the Examiner is invited to 
contact the Applicants' attorney at the telephone number listed below; 



Respectfully submitted, 



Margarfei M. Kelton, Reg. No. 44182 
One of the Attorneys for Applicant(s) 
LEYDIG, VOIT & MAYER, LTD. 
6815 Weaver Road, Suite 300 
Rockford, Illinois 61 1 14-8018 
(815) 963-7661 (telephone) 
(815) 963-7664 (facsimile) 

Date: October 1,2002 
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I hereby certify that this RESPONSE TO OFFICE ACTION (along with any documents 
referred to as being attached or enclosed) is being deposited with the United States Postal 
Service on the date shown below with sufficient postage as first class mail in an envelope 
addressed to: Commissioner for Patents, Box AF, Washington, D.C. 20231. 



Date: October 1 , 2002 
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